Method and system to process credit card payment transactions initiated by a merchant

ABSTRACT

A system, to process credit card payment transactions initiated by a merchant, includes an interface to receive a merchant-initiated request for a transfer of funds from a buyer credit card account. A credit card processing application initiates the transfer of funds from the buyer credit card account to a third-party merchant bank account, held by a third-party payment service. The third-party merchant bank account receives funds from the buyer credit card account on behalf of the merchant. A funds allocation application allocates the received funds to a receiving account of the merchant, the receiving account being maintained by the third-party payment service. The credit card processing application may be virtual point of sale (POS) terminal application, hosted at a server computer system operated by the third-party payment service, and accordingly may be accessible by the merchant via a network.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.10/941,510 filed Sep. 14, 2004, which is a continuation of PCTApplication PCT/US 04/22742 filed Jul. 16, 2004, the benefit of priorityof each of which is claimed hereby, and each of which are incorporatedby reference herein in its entirety.

FIELD OF THE INVENTION

An embodiment relates generally to the field of funds transferautomation, and more specifically, to a method and system to processcredit card payment transactions initiated by merchant.

BACKGROUND OF THE INVENTION

Credit cards (and debit cards that leverage credit card processingnetworks) are a widely used financial instrument. Accordingly, in orderto appeal to a broad base of potential buyers, it is advantageous formerchants to be able to receive payment for goods or services utilizinga buyer's credit card. In order to receive credit card payments,merchants are typically required to establish so-called merchant bankaccounts with acquiring banks, into which a credit card fund transfercan credit funds received in payment of goods or services. Theestablishment of a merchant bank account is not a trivial undertaking.Approval of a merchant bank account from an acquiring bank may takeweeks to receive. Further, there are numerous charges associated withthe maintenance and utilization of such merchant bank accounts. Forexample, an acquiring financial institution (e.g., a bank), with whichthe merchant bank account is established, typically charges discountrates (e.g., 2%-3% of a transaction total) to settle transactions. Thereare further reserve costs that the acquiring financial institution mayhold back to cover contested charges and charge back fees.

Credit card payments to a merchant bank account may furthermore bemerchant-initiated, as is the typical case in a “bricks-and-mortar”purchase scenario, or may be buyer-initiated where the transactionoccurs in an online environment. A brief discussion is provided belowregarding the processing of credit card transactions that are bothmerchant-initiated and buyer-initiated, within different environmentalcontexts.

FIG. 1 is a diagrammatic representation of a prior art credit cardtransaction processing scheme in the traditional “bricks-and-mortar”environment, where a buyer 10 is physically present at a seller location12, and accordingly able to present a credit card to the seller 14. Inthis scenario, in order to communicate the buyer's credit cardinformation to a credit card processing system, the seller 14 typicallymaintains an on-site Point Of Sale (POS) terminal 16. The seller 14swipes the buyer's credit card through the POS terminal 16, which thenprovides the relevant credit card information via a dialup connection,established over a Plain Old Telephone Service (POTS) network 18, to apayment gateway 20. The payment gateway 2.0 acts as interface betweenexternal networks (e.g., the POTS network 18 or the Internet) and aproprietary and secure network over which the various components of acredit card processing system may communicate.

The funds transfer request that is issued from the POS terminal 16, inaddition to including the credit card information of the buyer, alsoincludes (1) a merchant identification number, identifying the seller'smerchant bank account at an acquiring financial institution, and (2) aterminal identification number identifying the specific POS terminal 16.The terminal identification number is utilized to distinguish betweenmultiple POS terminals 16 that may be operated by the seller 14, forexample at various locations.

From the payment gateway 20, the funds transfer request is communicatedto an authorization system 22 for the authorization phase. Theauthorization system 22 communicates pertinent details of the fundstransfer request to an issuing bank 24, at which the buyer's credit cardaccount 26 is maintained. The issuing bank 24 will then make adetermination as to whether the buyer's credit card is valid and whetherthe buyer's credit card has the capacity to absorb the relevant charge.The authorization system 22 may also, in certain circumstances,communicate pertinent details of the funds transferred to anauthorization agent 28 (e.g. VISA, MASTERCARD, AMERICAN EXPRESS, etc.),which is distinct at the issuing bank 24, to determine whether therelevant credit card has been reported stolen or the authorization agentis aware of any other deficiencies. Having received. affirmativeauthorizations from the issuing bank 24 and/or the authorization agent28, the authorization system 22 will, via the payment gateway 20 and thePOTS network 18, communicate the authorization back to the POS terminal16, this authorization then being displayed to the seller. Responsive tothe authorization, the POS terminal 16 will also typically print areceipt for signature by the buyer 10.

Having now completed the authorization phase of a payment processingoperation, a settlement phase is then initiated. Specifically, the fundstransfer request, and the relevant authorization, are communicated to asettlement system 30. The settlement system 30 operates to transferauthorized funds for a transaction from the buyer's credit card account26 to the seller's merchant bank account 34. A settlement may beperformed in real-time, but is more typically performed as part of abatch operation once a day. The settlement process requires thesettlement system 30 to communicate details of the funds transfer,including the amount, and merchant identification information to boththe issuing bank and the acquiring bank. At the issuing bank 24, thebuyer's credit card account 26 is debited with the relevant charge, anda record created in the buyer's credit card account indicating, interalia, so-called “merchant of record” information, this informationidentifying the seller. At an acquiring bank 32, the seller's merchantbank account 34 is credited with the relevant amount. The seller'smerchant bank account 34 is identified utilizing the merchant identifiernumber communicated from the POS terminal 16. At the acquiring bank 32,the relevant funds may then be transferred from the seller's merchantbank account 34 to a seller's check account 36.

It will be noted that the seller's merchant bank account 34 is indicatedin FIG. 1 as being “present” merchant bank account, indicating that themerchant bank account 34 is associated with a physical POS terminal.Acquiring banks 32 may differentiate between a “present” merchant bankaccount, which receives payments where the buyer is “present” at aseller location and accordingly able to physically present a creditcard, and a so-called “not-present” merchant bank account, for which thecredit card information of the buyer is not received by the physicalpresentation of a credit card to the seller. The reason for thedifferentiation between “present” and “not-present” merchant bankaccounts is that the likelihood of fraud against “not-present” merchantbank accounts is higher, and accordingly the charges levied by theacquiring bank 32 for a “not-present” merchant bank accounts aretypically higher than those levied for “present” merchant bank accounts.

Continuing with merchant-initiated credit card payment transactions,FIG. 2 illustrates a credit card processing system to enablemerchant-initiated credit card payment transactions when the buyer 10 is“not-present” at a seller location, and accordingly unable to physicallypresent a credit card to the seller 14 to swipe through a POS terminal16. FIG. 2 illustrates that the buyer communicates order and credit cardinformation 40 to the seller 14 verbally during a telephone callestablished between the buyer 10 and the seller 14. Of course, the orderand credit card information 40 can be communicated utilizing any one ofa number of other mediums (e.g., fax, mail, email, web, phone etc.) tothe seller 14. In any event, the seller 14 receives the buyers 10 creditcard information without being physically presented the credit card, andaccordingly is unable to verify the signature on the credit card againstthe buyer's 10 signature. In this case, as the seller 14 does not havethe physical card, an alternative mechanism is required in order toenable the merchant to initiate a credit card payment transaction,utilizing the received credit card information.

Accordingly, a seller computer system 42, to which the seller 14 hasaccess, is shown to host and execute a virtual POS terminal application44, into which the seller 14 can input the buyer's 10 credit cardinformation. The seller computer system 42 is coupled by a network 46(e.g., the Internet) to a virtual POS terminal service provider 48,which in turn processes and forwards the credit card information to apayment gateway 20. From the payment gateway 20, payment processing(i.e., the authorization and settlement phases) is substantially similarto that described above with reference to FIG. 1. One difference will bethat the seller merchant bank account 34, maintained by the acquiringbank 32, would be flagged as a “not-present” merchant bank account inthis scenario.

FIG. 3 illustrates a typical prior art credit card processing systemthat enables such buyer-initiated payment transactions (as opposed tothe merchant-initiated transactions described above). In FIG. 3, theseller 14 operates a seller website (or marketplace) 50 that hosts apayment application 52 accessible, via a network 54 (e.g., the Internet)by a browser 56 executing on a client machine 58. The seller website 50may provide a catalogue of items for user purchase, and the paymentapplication 52 may provide a “check out” process to complete payment foritems selected for purchase by a buyer 10. Accordingly, the paymentapplication 52 may solicit credit card, and other personal information,from the buyer 10, via the browser 56, and communicate this information,again via the network 54, to the payment gateway 20. In certainapplications, the payment application 52 may be hosted on a serverexternal to the seller website 50, in which case the browser 56 may beredirected to a website of a payment service, which itself hosts thepayment application 52, in order to process payment for purchases madevia the seller website 50.

Once the payment gateway 20 receives the buyer's 10 credit cardinformation, the downstream processing of the transaction issubstantially similar to that described above with reference to FIG. 1.Again, it will be noted that, for this scenario, the seller merchantbank account 34 is designated as a “not-present” merchant bank account.

SUMMARY OF THE INVENTION

A method to process credit card payment transactions, initiated by amerchant, includes receiving a merchant-initiated request for a transferof funds from a buyer credit card account. The transfer of funds fromthe buyer credit card account to a third-party merchant bank account isinitiated, the third-party merchant bank account being held by athird-party payment service. The third-party merchant bank account is toreceive funds from the buyer credit card account on behalf of themerchant. The received funds are allocated to a receiving account of themerchant, the receiving account being maintained by the third-partypayment service.

Other features of the present invention will be apparent from theaccompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a diagrammatic representation of a prior art credit cardtransaction processing system that includes a physical POS terminal at aseller location to enable merchant-initiated credit card paymenttransactions.

FIG. 2 is a diagrammatic representation of a prior art credit cardtransaction processing system that includes a virtual POS terminal,hosted on a seller computer system, so as to enable merchant-initiatedcredit card payment transactions.

FIG. 3 is a diagrammatic representation of a prior art credit cardtransaction processing system that enables buyer-initiated credit cardtransaction processing by providing a buyer with access to a paymentapplication utilizing which the buyer can initiate a payment to aseller.

FIG. 4 is a block diagram illustrating an architecture of a system toprocess a credit card payment transaction, according to an exemplaryembodiment of the present invention.

FIG. 5 is a diagrammatic representation of a system to process creditcard payment transactions, according to an exemplary embodiment of thepresent invention, where credit card payment transactions aremerchant-initiated, and cause a transfer of funds from a buyer creditcard account to a “master” merchant bank account owned by a third-partypayment service.

FIGS. 6 and 7 present a flow chart illustrating a method, according toan exemplary embodiment of the present invention, to process credit cardpayment transactions initiated by a merchant.

FIG. 8 is a user interface diagram, illustrating an order entry userinterface, according to an exemplary embodiment of the presentinvention, that may be utilized by a seller to provide credit card andother personal information to a virtual POS terminal application hostedby a third-party payment service.

FIG. 9 is a user interface diagram illustrating an exemplary transactionfailed user interface that may be communicated to a user, in oneembodiment of the present invention, by a virtual POS responsive to adeclining of a credit card payment transaction.

FIG. 10 is a user interface diagram illustrating an exemplarytransaction success user interface that may, in one embodiment of thepresent invention, be presented to a seller user by a virtual POSterminal application hosted by a third-party payment service.

FIG. 11 is a diagrammatic representation of a machine, in the exemplaryform of a computer system, within which a set of instructions, forcausing the machine to perform any one of the methodologies discussedherein, may be executed.

DETAILED DESCRIPTION

A method and system to process credit card payment transactions,initiated by a merchant, are described. In the following description,for purposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the present invention. Itwill be evident, however, to one skilled in the art that the presentinvention may be practiced without these specific details.

FIG. 4 is a diagrammatic representation of a system 59 to process creditcard payment transactions, according to an exemplary embodiment of thepresent invention. The exemplary embodiment employs a client-serverarchitecture, and a payment service 64, operating in a server role, isaccessible via a network 54 (e.g., the Internet) by a number of clientmachines. Exemplary client machine 60 hosts a web client 61, in the formof a browser application, to enable a user of the client machine 60access to various applications hosted by, and forming part of, thepayment service 64. A further exemplary client machine 62 hosts avirtual POS programmatic access client 63, which facilitatesprogrammatic access to applications of the payment service 64. White theweb client 61 may be regarded as a “thin” client, the virtual POSprogrammatic access client 63 may be regarded as a “fat” client, andprovides enhanced functions, and/or performs a greater variety ofoperations on the client machine 62 than can be performed by the webclient 61.

Turning to the payment service 64, an interface to the service 64 isprovided, in an exemplary embodiment, by an Application ProgramInterface (API) server 66, which provides a programmatic interface, anda web server 68 (e.g., the MICROSOFT IIS WEB SERVER), which provides aweb interface to the payment service 64. One or more application servers70 host a number of payment applications 72, including a virtual POSterminal application 74, a funds allocation application 76, and aninvoicing application 78. The operations performed by these variousapplications are described in further detail below. Client applicationsare able to access the various payment applications 72, via the APIserver 66 and/or the web server 68, each of which is shown to be coupledto the application server 70.

The application servers 70 are coupled to one or more database servers80, which facilitate access by the payment applications 72 to one ormore databases 82. The databases 82, in the exemplary embodiment, areshown to store a user identification table 84 and a funded accountstable 86, in addition to a large number of other tables.

The virtual POS terminal application 74 is also able to establish aconnection, for the purposes of communicating data, with a paymentgateway 88, via the network 54.

FIG. 5 is a diagrammatic representation illustrating interaction of thesystem 59, described above with reference to FIG. 4, with elements of acredit card payment transaction processing system. The variousoperations performed by the components illustrated FIG. 4 are describedbelow with reference to the flow chart illustrated in FIGS. 6 and 7.Before commencing with the operational description, it should be notedfrom FIG. 5 that the payment service 64 has established a “master”third-party payment merchant bank account (MA) 100, optionally of the“not present” type, and a third-party payment service check account 102with an acquiring bank 98. The merchant bank account 100 is associatedwith the virtual POS terminal application 74, which is hosted on theapplication servers 70 of the payment service 64.

Also to be noted is that the funded accounts table 86 may containrecords for a receiving account, in the exemplary form of a sellerfunded account 87. The seller funded account 87 is associated with theseller 14, and includes a record of funds, maintained within thethird-party payment service check account 102, that belong to the seller14. The funded accounts table 86 is also shown to maintain records forfunded accounts for multiple registered users of the payment service 64.

FIGS. 6 and 7 illustrate a flow chart depicting a method 110, accordingto an exemplary embodiment of the present invention, to process creditcard payment transactions, where a merchant initiates the processing oftransactions. The method 110 commences at block 112, with the buyer 10placing an order for goods or services with the seller 14. In order toenable the seller 14 to receive payment for the goods or services, thebuyer 10 also provides the seller 14 with personal information includingcredit card information (e.g., a credit card number, buyer name, issuingauthority, expiration date etc.), and buyer identification information(e.g., an email address). The provision of the personal information may,for example, occur telephonically, as illustrated in FIG. 5, or may beachieved using any one of a number of other communication media (e.g.,email, web form, fax, mail, etc.). Accordingly, this scenario is what istraditionally regarded as a “not-present” presentation of credit cardinformation.

At block 114, now having the provided personal information in hand, theseller 14 accesses a virtual POS terminal application for the purposesof providing the buyer credit card information and email address to thevirtual POS terminal application. In one exemplary embodiment, where thevirtual POS terminal application 74 is hosted by the third-party paymentservice 64, this access may be provided via a browser application 75,hosted on a seller computer system 42. In an alternative embodiment, thevirtual POS application may comprise a client application that is hostedon the seller computer system 42. In other embodiments, the virtual POSapplication may be distributed, with certain components residing on theseller computer system 42, with other components residing on applicationservers 70 of the third-party payment service 64. In any event, theseller 14 inputs the personal information of the buyer into the virtualPOS terminal application at block 1114.

Considering an exemplary embodiment in which the virtual POS terminalapplication 74 is a fully hosted application, FIG. 8 illustrates anexemplary order entry interface 150 that may be generated by the virtualPOS terminal application 74, and communicated to the seller computersystem 42 via the network 54, for display by the browser application 75.The order entry interface 150 is shown to prompt the seller 14 forcustomer information 152, including an email address 154, order details156, and the buyer's credit card information. The order entry interface150 also includes notification information 160, prompting the seller 14to make the buyer 10 aware that the merchant of record information, aswill eventually appear on the buyer's credit card statement, willidentify both the third-party payment service 64 (e.g., ABC Corporation162), as well as the seller 14 (e.g. “JGOULDTESTO” 164).

At decision block 116 of the method 110, the virtual POS terminalapplication 74 makes a determination whether the buyer 10 is aregistered user of the third-party payment service 64. Thisdetermination is made by comparing the personal information, provided bythe seller with personal information, regarding registered users, storedwithin the user identification table 84. For example, the email address154 of the buyer 10 may be utilized to determine whether the buyer 10 isa registered user.

In the event that the virtual POS terminal application 74 determinesthat the buyer 10 is in fact a registered user, the invoicingapplication 78 is invoked to initiate a flow to enable the seller toissue an invoice to the buyer 10, via the third-party payment service64. In this case, the credit card information received at block 114 isdiscarded, and the processing of a credit card payment transaction isterminated at block 120. The invoicing application 78 may, for example,be an invoicing application such as that offered by PAYPAL INC., an EBAYCOMPANY.

Returning to decision block 116, should it be determined that the buyer10 is in fact not a registered user of the third-party payment service64 at block 112, the virtual POS terminal application 74 performs alook-up in the user identification table 84 to retrieve selleridentification information (e.g., a seller name) to be included in thetransaction of information to be provided to a payment gateway 88.

At block 124, the virtual POS terminal application 74 communicates afunds transfer request, via the network 54, to the payment gateway 88.The funds transfer request includes, inter alia, a merchantidentification number, identifying the third-party payment servicemerchant bank account 100, a terminal identification number, identifyingthe virtual POS terminal application 74, and the seller identificationinformation retrieved at block 122.

At block 126, the payment gateway 88 communicates the funds transferrequest to an authorization system 90, for authorization. Theauthorization system 90, in turn communicates pertinent information toan issuing bank 94, at which the buyer's credit card account 96 ismaintained.

At decision block 128, the authorization system 90 determines whetherthe funds transfer has been authorized or not. If not, at block 130, atransfer decline is communicated back from the authorization system 90,via the network 54, to the virtual POS terminal application 74, which inturn provides an appropriate communication back to the seller 114. Inone exemplary embodiment, this communication may take the form of atransaction failed user interface 166, an exemplary embodiment of whichis depicted in FIG. 9. The funds transfer request having been declined,the processing of the credit card payment transaction then againterminates at block 120.

On the other hand, should the funds transfer be authorized at decisionblock 128, the method 110 progresses to block 132, shown in FIG. 7. Atblock 132, the payment gateway 88 communicates the funds transferrequest to a settlement system 92 for settlement.

At block 132, the authorization system 90 will additionally communicatethe transfer approval back to the virtual POS terminal application 74,which may in turn again provide a communication to the seller 14 thatthe transaction has been approved. In one exemplary embodiment, thiscommunication may take the form of a transaction success user interface,in the exemplary form of a transaction success web page 170, an exampleof which is provided in FIG. 10.

At block 134, the settlement system 92 proceeds to debit the buyercredit card account 96, maintained at the issuing bank 94. Thesettlement system 92 further provides a merchant identifier (e.g., thename of the third-party payment service, ABC.COM), identifying thethird-party payment service 64, and the seller identificationinformation (e.g., the name of the seller 14, JGOULDTESTO) to theissuing bank 94 for inclusion within merchant of record information tobe associated with the buyer credit card account. This information willbe reflected on a credit card statement issued by the issuing bank 94 tothe buyer 10.

At block 136, the settlement system 92 then credits the merchant bankaccount 100 of the third-party payment service 64, which is maintainedat the acquiring bank 98. The settlement system 92 further communicatesthe seller identification information for association with anappropriate transaction record in the merchant bank account 100.

At block 138, the acquiring bank 98 transfers the received funds fromthe merchant bank account 100 to the check account 102 of thethird-party payment service 6.4 maintained at the acquiring bank 98.

At block 140, the funds allocation application 76, of the third-partypayment service 64, allocates funds to a receiving account (e.g., thefunded account 87) of the seller 14. The seller identificationinformation, provided at block 136, is utilized to determine what fundsreceived via the merchant bank account 100 and the check account 102 areproperly allocatable to the funded account 87 of the seller 14. In oneexemplary embodiment, the actual funds attributed (or allocated) to theseller 14 may be retained within the check account 102 of thethird-party payment service 64, with the funded account 87 maintaining arecord of a portion of the balance of the check account 102 that belongsto the seller 14. In another embodiment, the third-party payment service64 may in fact be a registered bank, and the allocation of fundsperformed at block 140 may involve an actual transfer of value from thecheck account 102 into a bank account (e.g., a check account) maintainedby the third-party payment service 64.

Accordingly, it will be appreciated that a “master” third-party merchantbank account 100 is enabled, via the third-party payment service 64, toreceive merchant-initiated credit card payments on behalf of multiplesellers 14, and then to distribute payments so received to receivingaccounts that are maintained by, or are accessible via, the third-partypayment service 64. This may be advantageous in that it allows multiplesellers 14 to leverage a merchant bank account 100 that has beenestablished, and is owned, by the third-party payment service 64.Accordingly, sellers 14 are spared the inconvenience and costsassociated with establishing individual merchants accounts with one ormore acquiring banks. Further, as the merchant bank account 100 mayreceive payments on behalf of a large volume of sellers 14, the size ofthe merchant bank account 100 may allow the third-party payment service64 to obtain certain cost efficiencies, which can optionally be passedon to the sellers 14. Additionally, the establishment of the third-partymerchant bank account 100 enables the third-party payment service 64 tooptionally provide the convenience of a virtual POS terminal application74 to any number of sellers 14, again without the inconvenience to thesellers 14 of having to establish individual merchant bank accounts.

FIG. 11 shows a diagrammatic representation of machine in the exemplaryform of a computer system 200 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In various embodiments, the machineoperates as a standalone device or may be connected (e.g., networked) toother machines. In a networked deployment, the machine may operate inthe capacity of a server or a client machine in server-client networkenvironment, or as a peer machine in a peer-to-peer (or distributed)network environment. The machine may be a personal computer (PC), atablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), acellular telephone, a web appliance, a network router, switch or bridge,or any machine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,white only a single machine is illustrated, the term “machine” shallalso be taken to include any collection of machines that individually orjointly execute a set (.or multiple sets)of instructions to perform anyone or more of the methodologies discussed herein.

The exemplary computer system 200 includes a processor 202 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU) orboth), a main memory 204 and a static memory 206, which communicate witheach other via a bus 208. The computer system 200 may further include avideo display unit 210 (e.g., a liquid crystal display (LCD) or acathode ray tithe ((CRT). The computer system 200 also includes analphanumeric input device 212 (e.g., a keyboard), a cursor controldevice 214 (e.g., a mouse), a disk drive unit 216, a signal generationdevice 218 (e.g., a speaker) and a network interface device 220.

The disk drive unit 216 includes a machine-readable medium 222 on whichis stored one or more sets of instructions (e.g., software 224)embodying any one or more of the methodologies or functions describedherein. The software 224 may also reside, completely or at leastpartially, within the main memory 204 and/or within the processor 202during execution thereof by the computer system 200, the main memory 204and the processor 202 also constituting machine-readable media.

The software 224 may further be transmitted or received over a network226 via the network interface device 220.

While the machine-readable medium 222 is shown in an exemplaryembodiment to be a single medium, the term “machine-readable medium”should be taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” shall also be taken to include any medium thatis capable of storing, encoding or carrying a set of instructions forexecution by the machine and that cause the machine to perform any oneor more of the methodologies of the present invention. The term“machine-readable medium” shall accordingly be taken to included, butnot be limited to, solid-state memories, optical and magnetic media, andcarrier wave signals.

Thus, a method and a system to process credit card payment transactions,initiated by a merchant, have been described. Although the presentinvention has been described with reference to specific exemplaryembodiments, it will be evident that various modifications and changesmay be made to these embodiments without departing from the broaderspirit and scope of the invention. Accordingly, the specification anddrawings are to be regarded in an illustrative rather than a restrictivesense.

What is claimed is:
 1. A system to process credit card paymenttransactions initiated by a merchant, the system including: an interfaceto receive a merchant-initiated request for a transfer of funds from abuyer credit card account; a credit card processing application toinitiate the transfer of funds from the buyer credit card account to athird-party merchant bank account, held by a third-party paymentservice, the third-party merchant bank account to receive funds from thebuyer credit card account on behalf of the merchant; and a fundsallocation application to allocate the received funds to a receivingaccount of the merchant, the receiving account being maintained by thethird-party payment service.